<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.35
     from ../directions.texi on 9 August 1996 -->

<TITLE>Z-Mail for the Future</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF">
<H1>Z-Mail for the Future</H1>


<H1><A NAME="SEC1" HREF="directions_toc.html#SEC1">Abstract</A></H1>

<P>
As Z-Mail enters its next major phase of development, a number of important
issues arise.  Careful decisions must be made to ensure that, as we address
these issues, we proceed with the proper balance of short-term productivity
and long-term stability and extensibility.  This document presents those
issues along with the context of our known marketing requirements and of
some of our long-standing desires for improvement of Z-Mail; this context
is valuable for identifying the correct resolutions to the issues.  The
goal of this document is not (at this writing) to present conclusions;
rather, it provides background for the decision and design processes.

</P>
<P>
This is a PROPRIETARY and CONFIDENTIAL DRAFT.
Have we said that often enough now?
This document is a work in progress; in particular, it's probably not at
this time fit for consumption outside Z-Code Division, as it frequently
fails to maintain the serious and pedantic tone so pompously established
in the preceding paragraph and so gleefully abandoned in this one.

</P>
<P>
Comments and critique are requested.

</P>



<H1><A NAME="SEC2" HREF="directions_toc.html#SEC2">Goals</A></H1>

<P>
This document is intended to provide a basis for discussion of future
Z-Mail development.  It covers market requirements and other desired
directions from the viewpoint of the user experience that we wish to
present, with an eye to comparable (not necessarily identical)
functionality across the several platforms we support.  An attempt is
made to summarize any known, open questions and issues regarding
development on each platform and how those relate to development across
all platforms.

</P>
<P>
I have also attempted to summarize herein many ideas for improvements
to Z-Mail that have been gathering electronic dust, sometimes for
years.  I have not, as of this draft, reconciled these ideas with the
<CITE>GNATS</CITE> change-request database, nor have I yet included ideas that
appear only in that database.

</P>
<P>
<STRONG>Note:</STRONG>
With the exception of required features (section <A HREF="directions.html#SEC3">Requirements</A>),
this document does <EM>not</EM>, at this time, define any specific course
of action with respect to development.

</P>


<H1><A NAME="SEC3" HREF="directions_toc.html#SEC3">Requirements</A></H1>

<P>
The following required features have been identified by NCD/Z-Code's
engineering or marketing staffs (staves?).  Most are described in more
detail in the document <CITE>Z-Mail 1995 Key Features -- Basic Market
Requirements</CITE>, last updated November 14, 1994.

</P>



<H2><A NAME="SEC4" HREF="directions_toc.html#SEC4">Baseline Assumptions</A></H2>
<P>
<A NAME="IDX1"></A>

</P>
<P>
There is a presumption in the following sections that Z-Mail already
conforms, or will after current projects are completed, to the following
baseline functionality:

</P>

<UL>

<LI>

<A NAME="IDX2"></A>
Z-Script in its old, crufty state (see section <A HREF="directions.html#SEC11">Improved Z-Script</A>), including
configurable user interface elements such as buttons, menus, and simple
window layout.

<LI>

<A NAME="IDX3"></A>
Basic support for MIME, including encoding non-ASCII text in message
headers, in all versions.

<LI>

<A NAME="IDX4"></A>
<A NAME="IDX5"></A>
Support for <STRONG>uuencode</STRONG> in all versions, and for <STRONG>binhex</STRONG> in at
least ZM-Mac.

<LI>

<A NAME="IDX6"></A>
Localizability of user interface and other user-visible strings in
all versions.

<LI>

<A NAME="IDX7"></A>
International character set translation for sending/receiving mail
in all versions.

<LI>

<A NAME="IDX8"></A>
<A NAME="IDX9"></A>
Serial dialup (aka <STRONG>asynch</STRONG>) capability in ZM-Win and ZM-Mac.

<LI>

<A NAME="IDX10"></A>
POP3<A NAME="FOOT1" HREF="directions_foot.html#FOOT1">(1)</A> support for access to
remote mail delivery in all versions.

<LI>

<A NAME="IDX11"></A>
Z-POP mailbox synchronization in at least ZM-Win and ZM-Mac.

<LI>

<A NAME="IDX12"></A>
Interactive spelling checker in at least ZM-Win and ZM-Mac.

</UL>



<H2><A NAME="SEC5" HREF="directions_toc.html#SEC5">IMAP</A></H2>
<P>
<A NAME="IDX13"></A>

</P>
<P>
The new <STRONG>Internet Message Access Protocol</STRONG>, or IMAP4,
specifications<A NAME="FOOT2" HREF="directions_foot.html#FOOT2">(2)</A>
provide a number of services desired by our customer base
(particularly universities, but lately an increasing number of our
corporate customers), including:

</P>

<UL>

<LI>

<A NAME="IDX14"></A>
<A NAME="IDX15"></A>
Centralized control of the message store -- previously available only
with X.400 servers or proprietary systems like HP's OpenMail;

<LI>

<A NAME="IDX16"></A>
Low-bandwidth access to messages -- in particular, selective retrieval of
MIME message parts;

<LI>

Storage of multiple mailboxes on the server, and access to all of them
from multiple client machines without having to copy the mail to each
client;

<LI>

Rudimentary synchronization of server mailboxes with client copies, for
disconnected use (presently supported in ZM-Win 4.0 via Z-POP, but only
for the primary delivery mailbox, not for multiple mailboxes).

</UL>

<P>
<A NAME="IDX17"></A>
<A NAME="IDX18"></A>
The marketing requirements document notes that Z-POP extensions for
more robust mailbox synchronization should be added to IMAP.  This
would require us to port, build, and maintain our own IMAP server;
there is some doubt that this would be cost-effective.

</P>
<P>
There also remains some question of whether the requirement is really
<A NAME="IDX19"></A>
for IMAP, or merely for the set of features IMAP4 provides.  It has
even been suggested that we develop
<A NAME="IDX20"></A>
our own HTTP-based mail server, on the assumption that IMAP4 is not
going to become widely available or commercially supported any time
soon.  There are, however, at least two noncommercial IMAP4 servers
presently in beta, and Sun will reportedly be supporting IMAP4 as part
of <CITE>ROAM</CITE>, their remote-mail initiative.

</P>


<H2><A NAME="SEC6" HREF="directions_toc.html#SEC6">Disconnected-mode Address Lookup</A></H2>
<P>
<A NAME="IDX21"></A>

</P>
<P>
<A NAME="IDX22"></A>
This is called "Local Directory" in <CITE>Z-Mail 1995 Key Features</CITE>.
This refers to the ability to have a subset of address directory
services (section <A HREF="directions.html#SEC19">Address Lookup</A>) available even when Z-Mail is not
connected to a network.  A small database, perhaps even a simple flat
file, must be retrieved from the mail server in a configurable way, and
later referenced by Z-Mail to verify and/or browse known addresses.

</P>
<P>
<A NAME="IDX23"></A>
<A NAME="IDX24"></A>
"Zync" configuration downloading (now a feature of Z-POP) or possibly
<A NAME="IDX25"></A>
even IMSP<A NAME="FOOT3" HREF="directions_foot.html#FOOT3">(3)</A>
option retrieval could be used to retrieve the database.

</P>
<P>
Open issues include designing the user interface components to control
what directory services are accessed (e.g., local or network).

</P>


<H2><A NAME="SEC7" HREF="directions_toc.html#SEC7">MIME Enhancements</A></H2>
<P>
<A NAME="IDX26"></A>

</P>
<P>
This is called "Improved MIME Compliance" in
<CITE>Z-Mail 1995 Key Features</CITE>.  This covers both bringing Z-Mail
into full <STRONG>MIME Conformance</STRONG> as defined by the latest
specifications<A NAME="FOOT4" HREF="directions_foot.html#FOOT4">(4)</A> and also
extending Z-Mail's support of the more esoteric features of MIME.

</P>
<P>
We presently handle the required types <STRONG>multipart/alternative</STRONG> and
<STRONG>multipart/digest</STRONG> only via external processing<A NAME="FOOT5" HREF="directions_foot.html#FOOT5">(5)</A> and only on the UNIX platform; so ZM-Win
and ZM-Mac are not fully conformant.  We would also like to extend our
support of MacMIME<A NAME="FOOT6" HREF="directions_foot.html#FOOT6">(6)</A> on all platforms.
<A NAME="IDX27"></A>

</P>
<P>
We are presently intentionally nonconformant in some specific cases
with respect to the requirement to "avoid showing users raw data ...
other than text." For example, we inline <STRONG>message/rfc822</STRONG> parts.
Executive decisions were made to the effect that users expected to
see certain types of data even though the MIME spec defines it as
non-text.

</P>
<P>
Also important is expanding our support of the many new optional MIME
types for special applications like enabled mail, security, etc.
See section <A HREF="directions.html#SEC26">Enabled Mail</A>.

</P>


<H2><A NAME="SEC8" HREF="directions_toc.html#SEC8">License Server (for ZM-Win/ZM-Mac)</A></H2>
<P>
<A NAME="IDX28"></A>

</P>
<P>
This item stems from ongoing confusion over what it means to license a
microcomputer-based mail client in a networked environment.  We at one
time announced that ZM-Win and ZM-Mac would be able to share ZCNLSD
license server capacity with UNIX Z-Mail installations.  We later decided
that, because the micro Z-Mails could operate offline or otherwise be
installed on individual machines that lack networking, network licensing
was not appropriate.

</P>
<P>
This dismayed some of our distributors, who saw network licensing as an
enforcement strategy, and some of our larger MIS customers, who saw it
as a way to monitor usage.

</P>
<P>
The current suggested resolution is to ignore the sniveling distributors
and to put some sort of user accounting into the ZPOP server to give the
customers their peace of mind.

</P>
<P>
<A NAME="IDX29"></A>
<A NAME="IDX30"></A>
<A NAME="IDX31"></A>
There is also the issue that PCX has adopted <CITE>FlexLM</CITE> -- if we do
decide to provide network licensing of ZM-Win, there will be pressure to
do so in the same manner as other NCD Software products.
See section <A HREF="directions.html#SEC12">NCD Software Integration</A>.

</P>


<H2><A NAME="SEC9" HREF="directions_toc.html#SEC9">Security</A></H2>
<P>
<A NAME="IDX32"></A>

</P>
<P>
Point-to-point mail encryption/authentication and local security
such as encrypted mail storage are included in this category.

</P>
<P>
We would like to support open standards such as MIME+PEM (aka
MOSS<A NAME="FOOT7" HREF="directions_foot.html#FOOT7">(7)</A> 
<A NAME="FOOT8" HREF="directions_foot.html#FOOT8">(8)</A> 
<A NAME="FOOT9" HREF="directions_foot.html#FOOT9">(9)</A>),
as well as some proprietary security
mechanisms:<A NAME="FOOT10" HREF="directions_foot.html#FOOT10">(10)</A>

</P>

<UL>

<LI>

AT&#38;T's <STRONG>Secret Agent</STRONG>;

<LI>

<STRONG>PKCS #7</STRONG><A NAME="FOOT11" HREF="directions_foot.html#FOOT11">(11)</A>;

<LI>

A system developed by Motorola;

<LI>

Others?

</UL>

<P>
However, these do not address encrypted mail storage except in so far
as that documents sent encrypted could be stored that way and decrypted
only upon display.

</P>
<P>
Outstanding issues with this include export restrictions, and supporting
proprietary systems without compromising our commitment to open standards.

</P>
<P>
Also related to security are issues of supporting a variety of user
authentication methods when contacting mail servers.  Examples include
<A NAME="IDX33"></A>
<A NAME="IDX34"></A>
the IMAP4 `AUTHENTICATE' command<A NAME="FOOT12" HREF="directions_foot.html#FOOT12">(12)</A> and its POP3
counterpart<A NAME="FOOT13" HREF="directions_foot.html#FOOT13">(13)</A>.

</P>


<H2><A NAME="SEC10" HREF="directions_toc.html#SEC10">Windows95</A></H2>
<P>
<A NAME="IDX35"></A>

</P>
<P>
In addition to the market demands, we now have (or soon will) a contractual
obligation to support the Windows95 desktop within 30 days of its release.
This obligation is only to <EM>run</EM> under Windows95, not to be fully
certified or otherwise integrated.  However, we will eventually want to
be a fully Windows95-native application; see section <A HREF="directions.html#SEC16">Desktop Integration</A>.

</P>


<H2><A NAME="SEC11" HREF="directions_toc.html#SEC11">Improved Z-Script</A></H2>
<P>
<A NAME="IDX36"></A>

</P>
<P>
See the marketing requirements document, and
especially section <A HREF="directions.html#SEC41">Z-Script Considerations</A>, and section <A HREF="directions.html#SEC15">Native Z-Script</A>.

</P>


<H2><A NAME="SEC12" HREF="directions_toc.html#SEC12">NCD Software Integration</A></H2>
<P>
<A NAME="IDX37"></A>

</P>
<P>
Although this is not discussed in the marketing requirements, NCD is
undertaking an effort to unify its software development strategy and
<A NAME="IDX38"></A>
impose some overall architectural goals for PCX, "Internet Products"
(Mariner), and Z-Code.

</P>
<P>
This affects Z-Mail development in several ways:

</P>

<UL>

<LI>

<A NAME="IDX39"></A>
<A NAME="IDX40"></A>
Mariner and Marathon include either Z-Mail or a "simplified" mail package
for which our division is nominally responsible; an upgrade path to full
Z-Mail is required.

<LI>

<A NAME="IDX41"></A>
An NCD "Look and Feel" will eventually be defined; we need to be
sure to have input into the design, especially for Mac and UNIX
platforms (on the assumption that Microsoft will largely dictate the
Windows95 look), and be prepared to adapt to the eventual decisions.

<LI>

<A NAME="IDX42"></A>
All NCD apps should interoperate to the greatest extent possible.  At
the moment, exactly what that means is too vague to expand upon here.
There is the possibility that it will come to mean that the Windows
and Macintosh versions of Z-Mail actually <STRONG>become</STRONG> Mariner, if
we can't do a good enough job of making an upgrade path to a more
powerful Z-Mail.

<LI>

<A NAME="IDX43"></A>
Z-Code is going to be increasingly looked on as a technology provider
for E-Mail capability that is included in other products.  This is the
other side of the "upgrade path" coin and relates to interoperability
as well.  We will need to identify components of Z-Mail that can be
built and used independently; and further, we will have to identify
which of those components can (and should) use platform-independent
code and which should be re-implemented on each platform.
See section <A HREF="directions.html#SEC30">Code Sharing</A>.

</UL>

<P>
All of this underscores our need and previously stated desire to do
significant work in modularizing Z-Mail.
See section <A HREF="directions.html#SEC28">Dynamic Feature Loading</A>,
section <A HREF="directions.html#SEC35">OLE2 Component Architecture</A>, and
section `Goals' in <CITE>Message Store API Requirements</CITE>.

</P>


<H1><A NAME="SEC13" HREF="directions_toc.html#SEC13">User Experience</A></H1>



<H2><A NAME="SEC14" HREF="directions_toc.html#SEC14">SMTP / POP / IMAP</A></H2>
<P>
<A NAME="IDX44"></A>
<A NAME="IDX45"></A>
<A NAME="IDX46"></A>

</P>
<P>
We remain dedicated to providing open-standards-based mail delivery through
established Internet protocols.  See section <A HREF="directions.html#SEC5">IMAP</A>.

</P>


<H2><A NAME="SEC15" HREF="directions_toc.html#SEC15">Native Z-Script</A></H2>
<P>
<A NAME="IDX47"></A>
<A NAME="IDX48"></A>

</P>
<P>
Although the configurability and programmability of Z-Mail through Z-Script 
has been one of our major selling points, it has several drawbacks, most
related to its intentional similarity to a UNIX shell program.
<A NAME="IDX49"></A>

</P>

<OL>

<LI>

The syntax is unfamiliar to non-UNIX users.  Even for UNIX users, some of
the syntax is painful.

<LI>

Variables are restricted to strings, numerics, or predefined lists
(<STRONG>multivalues</STRONG>) only.  Lack of ability to process external data
contained in files (except in the context of compositions and
attachments) also imposes many limitations.

<LI>

Although Z-Script is reasonably well-suited to manipulating mail
messages, other languages have become the defined or de facto standard
for interprocess communication (IPC) and for user-interface
programmability on the desktops we support.

</OL>

<P>
To address these problems, especially the last, we would like to be
able to program Z-Mail using the most natural "native" language on
each desktop:

</P>
<DL COMPACT>

<DT><EM>Windows</EM>
<DD>
<A NAME="IDX50"></A>
Visual Basic (VB) should be supported.

<DT><EM>Macintosh</EM>
<DD>
<A NAME="IDX51"></A>
<A NAME="IDX52"></A>
AppleScript should be supported; possibly VB as well.

<DT><EM>UNIX</EM>
<DD>
<A NAME="IDX53"></A>
<A NAME="IDX54"></A>
TCL<A NAME="FOOT14" HREF="directions_foot.html#FOOT14">(14)</A> may soon be the
language of choice; we may wish to support VB if a working cross-platform
interpreter can be obtained.

<DT><EM>Legacy installations</EM>
<DD>
Old Z-Script should continue working if at all possible.

</DL>

<P>
See section <A HREF="directions.html#SEC41">Z-Script Considerations</A>, and section <A HREF="directions.html#SEC16">Desktop Integration</A>.

</P>


<H2><A NAME="SEC16" HREF="directions_toc.html#SEC16">Desktop Integration</A></H2>
<P>
<A NAME="IDX55"></A>

</P>
<P>
Although we wish to provide a certain level of familiarity and comparable
functionality across all our supported platforms, we also wish to function
as a well-integrated application on the desktop in each environment.  The
following is an incomplete<A NAME="FOOT15" HREF="directions_foot.html#FOOT15">(15)</A> summary of areas that
present issues we must address for such integration.

</P>
<DL COMPACT>

<DT><EM>Windows</EM>
<DD>

<UL>

<LI>OLE2

<A NAME="IDX56"></A>

<LI>Extended MAPI

<A NAME="IDX57"></A>

<LI>Drag'n'drop

<A NAME="IDX58"></A>

</UL>

<DT><EM>Macintosh</EM>
<DD>
<A NAME="IDX59"></A>


<UL>

<LI>OpenDoc

<A NAME="IDX60"></A>

<LI>Drag'n'drop

<A NAME="IDX61"></A>

<LI>Apple Guide (online help system)

<A NAME="IDX62"></A>

</UL>

<DT><EM>X11/Motif</EM>
<DD>
<A NAME="IDX63"></A>
<A NAME="IDX64"></A>


<UL>

<LI>Common Desktop Environment (CDE)

<A NAME="IDX65"></A>
<A NAME="IDX66"></A>


<UL>

<LI>

Make Z-Mail understand session managers and how to register a restart
request with them.  This goes along with saving state of folders and
so on for later restart in case of a failure (machine crash etc.).

</UL>

<LI>Drag'n'drop

<A NAME="IDX67"></A>

</UL>

</DL>

<P>
Related topics are discussed in section <A HREF="directions.html#SEC29">Platform-Specific Issues</A>.

</P>


<H2><A NAME="SEC17" HREF="directions_toc.html#SEC17">Object-Oriented User Interface</A></H2>
<P>
<A NAME="IDX68"></A>

</P>
<P>
This refers to the ability to manipulate messages and message-related data
as objects, both through user actions like drag'n'drop and through Z-Script.
See section <A HREF="directions.html#SEC44">Z-Script Language Wish-List</A>.
In integrated desktop environments such as
<A NAME="IDX69"></A>
OLE2, this also means being able
to expose some set of those objects and interfaces to other applications.
See section <A HREF="directions.html#SEC12">NCD Software Integration</A>.

</P>


<H2><A NAME="SEC18" HREF="directions_toc.html#SEC18">Rich Text / Embedded Images</A></H2>
<P>
<A NAME="IDX70"></A>
<A NAME="IDX71"></A>

</P>
<P>
The new Ishmail product from HAL, and TCL/Tk enhancements to freeware
such as XMH, have moved the expectations for enhanced text and image
viewing in X11 mail systems beyond what Z-Mail provides.  NCD's own
Mariner product employs an HTML-based view window to display inline
images and fancy text, which ZM-Win (which is supposedly an upgrade
from Mariner's mail) does not.

</P>
<P>
It may be possible for us to incorporate HTML into Z-Mail on all platforms
to support this; see also section <A HREF="directions.html#SEC20">Cool Stuff</A>.

</P>


<H2><A NAME="SEC19" HREF="directions_toc.html#SEC19">Address Lookup</A></H2>
<P>
<A NAME="IDX72"></A>

</P>
<P>
<A NAME="IDX73"></A>
<A NAME="IDX74"></A>
This is also known as "Directory Services" or "Address Books". 

</P>
<P>
Z-Mail already provides a very basic interface to directory services.
However, there is increasing pressure to expand the interface and to
provide other directory mechanisms; see section <A HREF="directions.html#SEC3">Requirements</A>.  One
potential solution is to provide a sufficiently general interprocess
mechanism so that an outside agent could be written to access specific
services.

</P>
<DL COMPACT>

<DT><EM>Legacy Installations</EM>
<DD>
<A NAME="IDX75"></A>
Z-Mail has an established, extremely simple, protocol for accessing
directory services via an external program on UNIX and via a TCP/IP
connection to a specific port for ZM-Win and ZM-Mac.  We need to
consider whether to continue supporting these services, and whether
to extend the TCP-based service to the UNIX platform (as has been
requested by some customers).

<DT><EM>IMSP</EM>
<DD>
<A NAME="IDX76"></A>
Among other services, IMSP specifies a standard mechanism for accessing
and manipulating address books.  See section <A HREF="directions.html#SEC24">IMSP</A>.

<DT><EM>X.500</EM>
<DD>
<A NAME="IDX77"></A>
X.400/X.500 may be losing steam, but it would still be advantageous
to access these services, whether directly through an
LDAP<A NAME="FOOT16" HREF="directions_foot.html#FOOT16">(16)</A> API, or
indirectly via IPC.

<DT><EM>Proprietary Services</EM>
<DD>
We've had quite a bit of customer interest in connecting Z-Mail to
various proprietary directory service mechanisms.  These include:


<UL>

<LI>Microsoft Exchange (aka MSX)

<A NAME="IDX78"></A>
<A NAME="IDX79"></A>

<LI>Post (from AT&#38;T)

<A NAME="IDX80"></A>

<LI>OpenMail (from HP)

<A NAME="IDX81"></A>

<LI>Others?

</UL>

</DL>

<P>
Furthermore, we've been asked to make the
directory searches a bit more user-friendly.  Specifically, folks
have asked for us to support more intuitive searching, like hitting <KBD>t</KBD>
and getting all users whose name (first? last?) start with <SAMP>`t'</SAMP>.  Mail
systems that have tightly coupled directories are setting the standard
here, and our loosely coupled directory makes this type of interactive
thing hard or costly.

</P>


<H1><A NAME="SEC20" HREF="directions_toc.html#SEC20">Cool Stuff</A></H1>

<P>
This chapter is a compendium of things that it would be exciting to see
incorporated into Z-Mail.  Some of this is new technology; other parts
are enhancement we've wanted to make to existing capabilities.  In the
latter case, new technology may completely leapfrog the enhancements,
but I've mentioned them anyway for completeness.

</P>



<H2><A NAME="SEC21" HREF="directions_toc.html#SEC21">Mail Management</A></H2>
<P>
<A NAME="IDX82"></A>

</P>



<H3><A NAME="SEC22" HREF="directions_toc.html#SEC22">Database Aspects</A></H3>
<P>
<A NAME="IDX83"></A>

</P>
<P>
A mail program is, along with everything else it does, a database manager.
The typical mail program does not yet make use of the full power of a
database (and those that do are such awful mail programs that the database
<A NAME="IDX84"></A>
features can't save them; consider <CITE>Oracle Mail</CITE>).  Nevertheless, the
possibility of coupling Z-Mail to a database engine exists.
See section <A HREF="directions.html#SEC32">Extended MAPI</A>, for related considerations.

</P>
<P>
The following are some additional mail database management capabilities
that have been suggested for inclusion in Z-Mail.
See section <A HREF="directions.html#SEC43">Z-Script and Mail Management</A>, for commentary on how mail should
be accessed and manipulated from the scripting language.

</P>

<UL>

<LI>

Save messages in multiple folders without duplicating content.  A
closely related issue is that storage requirements of SMTP-based
systems (i.e., message copied to each user) are a great concern to users,
and a consistent issue raised by the vendors of proprietary systems.
Anything we can do in the user agent (i.e., detached body parts or
something like it) would be extremely helpful, even if just applicable
to local users.

<LI>

Provide keyword search, cross referencing, etc. without actually having to
open every folder that is to be searched.

<LI>

Cache a list of everything that's in the user's standard folder area
(<CODE>$folder</CODE>) and update the list as folders are added and removed.


<BLOCKQUOTE>
<P>
UI items that should be notified are cascade (pullright) menus
for folder access and the folder dialogs, or anything else that
might display folder names.
</BLOCKQUOTE>

<LI>

Make indexing more configurable with respect to file name, whether it
is in the folder by default or elsewhere, etc.

<LI>

Support more (and even perhaps customizable) mailbox formats (get
<A NAME="IDX85"></A>
<A NAME="IDX86"></A>
MH fully working, support Rmail (?), compressed folders, etc.)

<LI>

Expand the way <CODE>dot_lock</CODE> works in conjunction with kernel locks.

<LI>

Provide special locking for group-accessed mailboxes (see
section <A HREF="directions.html#SEC44">Z-Script Language Wish-List</A>, the suggested
<CODE>lock</CODE> and <CODE>unlock</CODE> commands).

<LI>

For flat-file folders, use a faster string-search (e.g. Boyer-Moore) to
find the beginning of each message in a folder, to construct a partial
index from which we can then load quickly.  Probably a win only on big
folders lacking a preconstructed Z-Mail index, and we may be switching
to better folder formats entirely.

<LI>

Provide some kind of ongoing save of state, at least of folders but ideally
of the entire Z-Mail session, for recovery after system crash etc.  For
example, periodically update external folder indices.

<LI>

Trace threads and insert extra info (headers?) so that the thread
can be followed either forward or backward even if things
are deleted from the middle or beginning of the thread.

<LI>

File descriptor limits prevent users from keeping many folders open at
once.  This should be addressed by any new message management scheme.

</UL>



<H3><A NAME="SEC23" HREF="directions_toc.html#SEC23">Mail Interactions</A></H3>
<P>
<A NAME="IDX87"></A>

</P>
<P>
The following are all ways in which we should improve Z-Mail's capabilities
for sending and receiving messages.

</P>

<UL>

<LI>

Perfect parsing of bizarre addressing syntax.

<LI>

Do X.500-style address input (prompt for address fields).

<LI>

Specify a different file name when attaching a file than its
actual name (to avoid conflicts for the recipient when attaching
files having the same name from different directories).

<LI>

Save compositions-in-progress upon exit from zmail and restore them on
restart.

<LI>

Be able to do attachments (and possibly also addressing, if
edit_hdrs is NOT set) while running an external editor, at least
in GUI.

<LI>

Allow attaching directories (tarmail?).

<LI>

It should be possible to specify case-<EM>in</EM>sensitive alias expansion.

<LI>

Permit wildcard matches when listing alias names.
E.g., <CODE>alias *sgi*</CODE>.

<LI>

When <EM>displaying</EM> an attachment, and its file exists, and the user is
asked to yes/no/cancel an overwrite, and he says no, try to do the display
anyway by writing to an invented filename.  This implies some sort of
test that errs on the side of caution to determine whether the existing
file is a correct copy previously detached, before going through another
decoding pass.

<LI>

Prompt for a program to run when attempting to display a type for which
no program has been supplied.

<LI>

Do more checking before send in edit_hdrs mode to try to get the user
to make a sensible RFC822 header including the blank line between
headers and body before letting him leave the editor.

<LI>

User-definable addressing formats for addresses generated by <CODE>reply</CODE>
or inserted into From: lines.

<LI>

Provide <STRONG>group bcc</STRONG> wherein the <CODE>gbcc</CODE>'d group can see
themselves in the headers, but others can't see them.  Painful.

<LI>

Permit personal headers (<STRONG>Envelope</STRONG>) to be kept in a file.

<LI>

Have some way (in the contents of the message headers/body?) for the
external editor to tell Z-Mail to send/cancel/etc. the composition it
was editing.

<LI>

Ignore (hide) ignored headers even when composing with edit_hdrs

<LI>

Ignored and retained headers should use case-insensitive matching even
when doing a wildcard (glob) match.

<LI>

Attachment types need to be mode-specific, e.g. a way to specify
different display programs for Motif than for Lite/CLI/etc.

<LI>

<A NAME="IDX88"></A>
<A NAME="IDX89"></A>
Provide an <STRONG>Mail Transport Agent description language</STRONG> to define the
interface from Z-Mail to some arbitrary MTA, so we don't require shell
processes.

<LI>

Supply the equivalent of <CODE>filter</CODE> for outgoing compositions.

<LI>

Have an option to run filters at update time instead of at newmail arrival.
(How do you know what messages NOT to filter?  Are there any such?)

<LI>

Match arriving messages against <CODE>logfile</CODE> or <CODE>record</CODE> to see
if an urgent reply has been received.  Store additional headers in
those messages to show when the reply was received, etc.

<LI>

Disable alias lookup when doing a <CODE>reply</CODE>.  (How?)

<LI>

The <CODE>-send</CODE> option shouldn't require a file if there's an attachment.

<LI>

When the user changes a variable to automatically add the original
message to a reply, there should be a menu option (and key command) to
bring up a reply window <EM>without</EM> the original message.
In other words, the menu items <SAMP>`Sender (Include Message)'</SAMP> and
<SAMP>`All (Include Message)'</SAMP>
should toggle to <SAMP>`Sender (Don't Include Message)'</SAMP> and
<SAMP>`All (Don't Include Message)'</SAMP> when the user has set
the default (via <CODE>autoinclude</CODE>) to <SAMP>`Include'</SAMP>.

<LI>

Spot uuencoded or otherwise "wrapped"
blocks of machine-readable data in the body of RFC822 messages
and treat them as "attachments" -- some gateways (e.g. <CITE>QuickMail</CITE>)
just dump uuencoded or binhexed blobs into the body and their UA looks for
the <CODE>begin</CODE> line to treat them as attachments.  (ZM-Mac does this
to some degree already.)

<LI>

Optionally suck in new mail in "background" folders like we do with
the spool folder.

<LI>

Make generation of a message-id settable via <CODE>picky_mta</CODE>.

<LI>

The <CODE>mail -draft</CODE> command should recognize when the draft file
contains attachments and then reattach them.  It works properly if you
use <CODE>-send -draft</CODE> (that is, don't re-edit the headers).  (This
is now supported by <CODE>mail -q</CODE>, but should work with <CODE>-draft</CODE>
or some similar option from the UNIX shell command line.)

<LI>

<CODE>compcmd get-header</CODE> should take the name of a variable into which
to place the requested header, rather than always using <CODE>header_value</CODE>
(which is also used by the dynamic-headers interface, which is why it
is the thing <CODE>get-header</CODE> affects).

</UL>



<H2><A NAME="SEC24" HREF="directions_toc.html#SEC24">IMSP</A></H2>
<P>
<A NAME="IDX90"></A>

</P>
<P>
The
<STRONG>Internet Message Support Protocol</STRONG><A NAME="FOOT17" HREF="directions_foot.html#FOOT17">(17)</A>
is a companion to the
<A NAME="IDX91"></A>
IMAP4 protocol; it extends some of the IMAP4 services, and provides
others that are considered beyond the scope of mail access.  This
includes directory services, configuration management, and access
control lists (granting or restricting access to shared mailboxes).

</P>
<P>
An IMSP/IMAP4 client would typically connect to <EM>both</EM> IMSP and
IMAP4 servers, using the IMSP server for mailbox management and other
services, and using the IMAP4 server for actual message retrieval.

</P>


<H2><A NAME="SEC25" HREF="directions_toc.html#SEC25">Forms Support / Workflow Automation</A></H2>
<P>
<A NAME="IDX92"></A>
<A NAME="IDX93"></A>

</P>
<P>
We've long had requests to provide, either through a companion application
or Z-Script, the ability to define custom forms with editable fields that
can be mailed from person to person or to automated mail servers.

</P>
<P>
There have been discussions with third parties such as Delrina, but as
yet nothing has solidified.

</P>
<P>
Another solution that has recently been put forth is to incorporate
<A NAME="IDX94"></A>
HTML+<A NAME="FOOT18" HREF="directions_foot.html#FOOT18">(18)</A>
into Z-Mail, possibly by leveraging the Mariner team's expertise in
this area.  HTML+ provides a <STRONG>mailto</STRONG> submission protocol for forms,
<A NAME="IDX95"></A>
in addition to HTTP-based
submissions.<A NAME="FOOT19" HREF="directions_foot.html#FOOT19">(19)</A>
There remains some question of whether this mechanism is powerful
enough to handle all the applications we would desire; a submission
mechanism that returned control of the form to Z-Mail for further
manipulation (as an attachment to a composition) would be preferable
in many cases.

</P>
<P>
Several users have asked for "query-by-example" types of forms for 
searching or filtering.  In other words, to define a filter you would
bring up a message window and fill in the parts you want to match.

</P>


<H2><A NAME="SEC26" HREF="directions_toc.html#SEC26">Enabled Mail</A></H2>
<P>
<A NAME="IDX96"></A>

</P>
<P>
Also known as "Active Messaging", 
this takes forms and workflow to the next level, permitting mail messages
to contain actual programs that perform some service for the recipient.
The current proposal<A NAME="FOOT20" HREF="directions_foot.html#FOOT20">(20)</A> for enabled mail is to use
<A NAME="IDX97"></A>
Safe-TCL as the standard language in a MIME type
<STRONG>application/Safe-Tcl</STRONG> within a container called
<STRONG>multipart/enabled-mail</STRONG>.

</P>
<P>
We really should add support for this, if only because First Virtual uses
it for transaction notifications.

</P>


<H2><A NAME="SEC27" HREF="directions_toc.html#SEC27">Multithreading</A></H2>
<P>
<A NAME="IDX98"></A>

</P>
<P>
Besides being a good word to be able to buzz, it's cool.

</P>
<P>
Multithreaded applications can handle expensive tasks more effectively;
in particular, they can be much more responsive to user interaction
during time-consuming operations.  For tasks that are actually
<A NAME="IDX99"></A>
performed remotely (e.g., IMAP4 searches), a multithreaded application
can continue with other processing while still monitoring the remote
connection for a response.

</P>
<P>
Further, designing and programming for multithreaded operation fits well
with plans to break up Z-Mail's technology into reusable components.
See section <A HREF="directions.html#SEC35">OLE2 Component Architecture</A>.

</P>


<H2><A NAME="SEC28" HREF="directions_toc.html#SEC28">Dynamic Feature Loading</A></H2>
<P>
<A NAME="IDX100"></A>
<A NAME="IDX101"></A>

</P>
<P>
In order to make a smaller, faster Z-Mail, and possibly to market selected
features separately from the main product, we would like to make individual
features dynamically loadable.  We do this in a rudimentary way today with
the toolbars of the Motif version, by defining Z-Script functions that wait
to create the buttons and load the icons until the user actually requests
that the toolbar be displayed.

</P>

<P>
Note that dynamically loadable features does <EM>not necessarily</EM> mean
dynamically loaded libraries (DLLs).  Some features might be run-time
loaded Z-Script, if the language can be made powerful enough to support
that more completely and efficiently.  See section <A HREF="directions.html#SEC15">Native Z-Script</A>.

</P>
<P>
See also section <A HREF="directions.html#SEC35">OLE2 Component Architecture</A>.

</P>


<H1><A NAME="SEC29" HREF="directions_toc.html#SEC29">Platform-Specific Issues</A></H1>

<P>
This section is designed to be filled out as design discussions progress;
items may shift from this section to others as solutions are identified.

</P>



<H2><A NAME="SEC30" HREF="directions_toc.html#SEC30">Code Sharing</A></H2>
<P>
<A NAME="IDX102"></A>

</P>
<P>
One general question that may have a different answer for each platform
is the issue of what code is shared and what code is reimplemented for
each platform.  This is of particular concern for platforms such as
Windows and potentially Macintosh, where we will depend on being able
to plug in to an externally-defined object model for both integration
with the desktop and interoperability with other applications (including
drop-in technology components for other NCD Software apps).
<A NAME="IDX103"></A>

</P>
<P>
<A NAME="IDX104"></A>
As an especially relevant example, Microsoft's <CITE>MFC</CITE> class library
provides drop-in interfaces to nearly all OLE2 embeddable objects (and
soon will include both Simple and Extended MAPI interfaces as well).
If we choose to use OLE2 storage objects for filesystem access on
Windows (as suggested by the sample hierarchy in section <A HREF="directions.html#SEC35">OLE2 Component Architecture</A>) then any code that manipulates file-like objects will
have to be able to access OLE2 storage, and probably should do so
through MFC.

</P>
<P>
If such file access code is to be shared across platforms, we must
carefully define the file access calls that it is permitted to make so
as to map onto either MFC or (say) <CITE>stdio</CITE> as appropriate to the
platform.  The issue in such cases is, is it more work to provide those
mappings, or to reimplement the code on each platform rather than
sharing it?

</P>


<H2><A NAME="SEC31" HREF="directions_toc.html#SEC31">Windows</A></H2>
<P>
<A NAME="IDX105"></A>

</P>



<H3><A NAME="SEC32" HREF="directions_toc.html#SEC32">Extended MAPI</A></H3>
<P>
<A NAME="IDX106"></A>

</P>

<UL>

<LI>

How does the EMAPI client module work?

<LI>

How do we replace the default service provider with our service module?

<LI>

Does the server module require a Microsoft Exchange (MSX) message store,
or can other providers be plugged in?

</UL>



<H3><A NAME="SEC33" HREF="directions_toc.html#SEC33">OLE2 <EM>vs.</EM> OpenDoc</A></H3>
<P>
<A NAME="IDX107"></A>
<A NAME="IDX108"></A>
Is there really a choice here?

</P>


<H3><A NAME="SEC34" HREF="directions_toc.html#SEC34">OLE2 Integration</A></H3>
<P>
<A NAME="IDX109"></A>

</P>

<UL>

<LI>

Do we make a fully OLE2 app?

<LI>

To what degree do we use a common code base to support common functionality
across platforms?

<LI>

How do we "route" functionality that is supported across platforms
by a common code layer, in and out of the OLE2 components?

<LI>

How "deeply" does any common code (the "core") have to understand OLE2?
(This is particularly important in the case of using OLE structured storage
for file management.)

<LI>

What OLE2 objects do we expose to other OLE2 apps?

</UL>



<H3><A NAME="SEC35" HREF="directions_toc.html#SEC35">OLE2 Component Architecture</A></H3>
<P>
<A NAME="IDX110"></A>

</P>
<P>
Support for OLE2 will be extremely important for integrating Z-Mail both
with other applications and ultimately with new versions of the Windows
operating system itself.<A NAME="FOOT21" HREF="directions_foot.html#FOOT21">(21)</A>
<A NAME="IDX111"></A>
Even within NCD Software, it will be advantageous for us to
push for adoption of a scheme that permits us to supply drop-in mail
<A NAME="IDX112"></A>
components for other apps like Mariner (section <A HREF="directions.html#SEC12">NCD Software Integration</A>);
OLE2 is the most likely candidate.

</P>
<P>
John DeBriere writes in
<CITE>Making Z-Mail OLE 2.0x Compliant</CITE><A NAME="FOOT22" HREF="directions_foot.html#FOOT22">(22)</A>:

</P>

<BLOCKQUOTE>
<P>
OLE 2.0x is a specification designed [to provide for] applications to
interoperate seamlessly with one another.  [Although] OLE is largely
designed around compound documents, it offers much more than document
centric support.  OLE exposes system features and services through
Microsoft's component object model (COM).  OLE 2.0x is a means to
provide programmable objects through automation, persistent custom
controls, a uniform means of transferring data between applications,
and the coming object oriented operating system, Cairo.
</BLOCKQUOTE>

<P>
A sample component hierarchy<A NAME="FOOT23" HREF="directions_foot.html#FOOT23">(23)</A> might
look like this:

</P>

<UL>

<LI>User Agent (container)


<UL>

<LI>

Message Reader (container)


<UL>

<LI>

Summary Viewer (control)

<LI>

Attachment Viewer (control)

<LI>

Text Viewer (control)

</UL>

<LI>

Message Composer (container)


<UL>

<LI>

Address Book (control)

<LI>

Attachment Editor (control)

<LI>

Text Editor (control)

</UL>

</UL>

<LI>

Outbound Mail Service

<BLOCKQUOTE>
<P>
(Connected to UA via <STRONG>advise</STRONG> and <STRONG>storage</STRONG> interfaces.)
</BLOCKQUOTE>


<UL>

<LI>

Assembly Agent (MIME, uuencode, etc.)

<LI>

SMTP Client

<LI>

Socket Layer

</UL>

<LI>

Inbound Mail Service

<BLOCKQUOTE>
<P>
(Connected to UA via <STRONG>advise</STRONG> and <STRONG>storage</STRONG> interfaces.)
</BLOCKQUOTE>


<UL>

<LI>

Socket Layer

<LI>

POP or IMAP Client

<LI>

Disassembly Agent

</UL>

</UL>

<P>
Obviously, other hierarchies are possible; for example, it may not be
desirable to perform message assembly and disassembly in the outbound
and inbound service modules if the UA wants to treat messages as
RFC822 entities or if a remote server already performs some
disassembly (as with IMAP4).

</P>
<P>
The important thing to note is that, if the components are created
properly, rearranging them, replacing them, or even duplicating
capability in different parts of the hierarchy can easily be accomplished.

</P>


<H2><A NAME="SEC36" HREF="directions_toc.html#SEC36">Macintosh</A></H2>
<P>
<A NAME="IDX113"></A>

</P>

<UL>

<LI>

<A NAME="IDX114"></A>
Do we support OpenDoc, or OLE2?

<LI>

<A NAME="IDX115"></A>
<A NAME="IDX116"></A>
<A NAME="IDX117"></A>
How and when do we take advantage of X/Open's <CITE>XTI</CITE> networking
interface (named <CITE>OpenTransport</CITE> on the Macintosh)?

<LI>

<A NAME="IDX118"></A>
To what extent do we conform to the Apple Object Model, thereby exposing
the UI elements and features of our application to others?

</UL>

<P>
(I'm sure the Mac team has other issues, along with sharing a number of
the platform-related issues discussed elsewhere in this document.  This
section will be expanded as necessary.)

</P>


<H2><A NAME="SEC37" HREF="directions_toc.html#SEC37">UNIX</A></H2>
<P>
<A NAME="IDX119"></A>

</P>



<H3><A NAME="SEC38" HREF="directions_toc.html#SEC38">Lite (character terminals)</A></H3>
<P>
<A NAME="IDX120"></A>

</P>
<P>
The Lite menus need some concentrated review.  Using the menus can be 
exremely frustrating, as one cannot just "walk through" the menus using
unique keys.  For example, there are two menus invoked with <KBD>F</KBD> on the
main menu.  One should be able to walk the menus with unique keys, as with
<CITE>Lotus 1-2-3</CITE>, all Windows applications, and so on.

</P>
<P>
Otherwise, Lite seems to be nearly perfect, except for a few bugs.
Relatively minor changes to keep its UI elements up to date with
respect to changes in the other UIs and in underlying functionality
would probably be adequate, once all the features in
section <A HREF="directions.html#SEC4">Baseline Assumptions</A>, are satisfied.

</P>
<P>
However, it might be worthwhile to look into converting Lite's
object-oriented internals from our
<CITE>SPOOR</CITE><A NAME="FOOT24" HREF="directions_foot.html#FOOT24">(24)</A>
toolkit into real C++.

</P>


<H3><A NAME="SEC39" HREF="directions_toc.html#SEC39">X11/Motif</A></H3>
<P>
<A NAME="IDX121"></A>
<A NAME="IDX122"></A>

</P>
<P>
The following are all wish-list or other suggested items for improving
the Motif user interface.  Other interfaces may also be able to pick up
some hints here.

</P>

<UL>

<LI>

Dynamically select different-sized icons based on screen size.

<LI>

Better context-sensitivity in on-line help system.

<LI>

Click on the main window's iconify button and all the windows iconify.
Main window WM-initiated iconify button should iconify all frames that
are children of the main window.  (Hmmm..... not sure about this.)

<LI>

Check for new mail on de-iconify or other visibility changes.  This
is partly workable today through Xt translations, if you're willing
to put up with some harmless warnings at startup.

<LI>

Add the ability to "cache" one or more xterm windows for use by external
editors, etc., so a new process need not always be started.  Better
yet, add a terminal-emulator widget.

<LI>

Duplicate a copy of the Output Area contents in a separate dialog that
can stay up somewhere all the time.

<LI>

Message display window "attached" to main window (like MailTool).

<LI>

Save X configurations other than fonts/colors (geometry, etc.).  Some
of this is now available, particularly in MediaMail.

<LI>

Show current colors of selected objects in colors dialog; reset it
somehow (make the toggles into radio buttons?) to avoid accidents.

<LI>

Support for full-color icons; another place where Ishmail has passed us.

<LI>

Use mixed icons and text in lists, especially the main message summaries.
Ishmail again.

<LI>

Make window dumps or other graphical images and expand the help system
to be able to recognize and display them.

<LI>

The sliders in the Variables dialog should be linked to a numeric
textfield, so you can type in specific values instead of tweaking the
slider to get them.

<LI>

The Z-Mail main window should remain 80 columns wide even if the Command:
field is not present.

<LI>

Display the current input line/column in the compose window.

<LI>

The message headers for the message reading window should be more
structured for easier reading, possibly using a mixture of normal,
bold and italic.

<LI>

Allow two-way cross-referencing in the help system without going into an
infinite loop.  Allow any entry to cross-reference more than one other entry.

<LI>

Do a "quick quit" by forking at some point during the quit procedure
and having the child finish up.

<LI>

The Attachments dialog should have a <STRONG>dirty</STRONG> state, when the type
or encoding has been changed but nothing has been done about it.  When
in this state, Done should be handled like the Compose dialog with Done
vs. Cancel: pop up a confirm box.  (Do the Motif-2.0-compliant Close
and Cancel buttons cover this adequately?)

<LI>

See message summaries of all open folders simultaneously;
multiple message summary panes

<LI>

Timestamp <CODE>X Error</CODE> and <CODE>Xt Error</CODE> messages.

<LI>

Double-clicking in any list where there are multiple possible actions
should perform the action most likely to <EM>display</EM> the clicked item.
(This rule is used in some places but we should review whether it is
properly applied everywhere.)

<LI>

The list of actions in the Pattern and Date search dialogs could be
sensitive at all times, but have no selection when
<SAMP>`Perform Function'</SAMP> is
toggled off.  If a selection is made, toggle
<SAMP>`Perform Function'</SAMP> back on
automatically.  (This request needs review before we commit to it.)

<LI>

Regarding having the search wrap around from the top, I'd prefer
it to come up with a dialog that says "no more matches to bottom
of file, search again from the top?" with OK and Cancel (or is it
Done?) buttons.  (Ruth 12/01/93)

<LI>

Full headers toggle should work for pinups.

<LI>

<SAMP>`Edit Functions'</SAMP> from <SAMP>`Buttons'</SAMP> dialog should come up with the
function that goes with the currently selected button already
selected.

<LI>

When you set a new alias, the selection should be placed on the alias
which was updated/created, and it should be scrolled to the top of the
list.

<LI>

It would be nice to have the <KBD>Page up</KBD> and <KBD>Page down</KBD> keys working
on the main window as well (perhaps under the <SAMP>`View'</SAMP> pulldown) so that
you don't have to have focus on the message summary list.

<LI>

When the main message summaries window is stretched, the message
subject clauses do not fit-to-screen. i.e. the text does not enlarge.

<LI>

It should be easy to preview your X-face.  Perhaps compose window
should show user's X-face.  This may conflict with a drag-n-drop
design where you can drop other people's faces on a compose window to
mail to them.

</UL>



<H3><A NAME="SEC40" HREF="directions_toc.html#SEC40">Command-Line Interface</A></H3>
<P>
<A NAME="IDX123"></A>

</P>
<P>
The CLI is mostly defined by Z-Script, as it is essentially an interactive
Z-Script interpreter.  See section <A HREF="directions.html#SEC41">Z-Script Considerations</A>, for an extensive
list of changes that might be reflected in the CLI.

</P>
<P>
Other wishlist items:

</P>

<UL>

<LI>

At one time we sought to provide command and variable-setting compatibility
with all standard UNIX CLI mail programs, such as <CITE>mailx</CITE>.  At present,
even our Z-Script emulations (provided as samples with the distributions)
are woefully out of date.  Bring them up to speed.

<LI>

Expand word completion to history, variables, etc. as appropriate.

<LI>

Allow <CODE>~:source</CODE> in line mode while composing messages.

<LI>

The <CODE>~l!</CODE> tilde-command should probably turn off <CODE>record_users</CODE>.

</UL>



<H1><A NAME="SEC41" HREF="directions_toc.html#SEC41">Z-Script Considerations</A></H1>
<P>
<A NAME="IDX124"></A>

</P>
<P>
This section lists a number of desired enhancements to Z-Script and to its
interactions with the rest of Z-Mail.  Any new language solutions we come
up with (section <A HREF="directions.html#SEC15">Native Z-Script</A>) should include some consideration of these
features.

</P>



<H2><A NAME="SEC42" HREF="directions_toc.html#SEC42">Z-Script and the User Interface</A></H2>
<P>
<A NAME="IDX125"></A>
<A NAME="IDX126"></A>

</P>
<P>
The following are some longstanding wish-list items for Z-Script's
interaction with the user interface.

</P>

<UL>

<LI>

<STRONG>Preferences</STRONG> menus and/or dialogs for quick/simple access to
logical sets of configuration variable settings.

<LI>

Indicate when the state of functions or variables needs saving.

<LI>

Specify the height of the list displayed in the <CODE>ask</CODE> dialog.

<LI>

Add variables to permit enumeration of "uninteresting" attachment types
(for which the icons and/or icon bar should not be shown).

<LI>

Make <CODE>folder -N</CODE> in GUI mean, "Open this folder, but do not make
it the folder displayed in the main window."  Either we need a way to
open a "background" folder, or we need to allow the current folder
to be one other than that displayed in the main window.

<LI>

Permit multiple copies of each dialog, and graphically connect them
(<STRONG>GUI pipelines</STRONG>, e.g., full functionality of original Toolbox design)
Provide a way to save the pipeline somehow (script file or function).

<LI>

Support command history in the GUI (<STRONG>Lite</STRONG> does this already).

<LI>

<STRONG>Hide</STRONG> threads of messages, e.g. only display summary of only the
earliest message in the thread plus some indication of the
number of messages in the thread ("folding" of threads).

<LI>

Add a <CODE>umask</CODE> command (UNIX only).  If so, the system.zmailrc should
probably have <CODE>umask 077</CODE> added to it.

<LI>

If a new message comes in to an empty folder, select it in the GUI
automatically.

<LI>

Provide an interactive dialog to define attachment types, and/or text
fields on the attachments dialog to show the associated programs.

</UL>



<H2><A NAME="SEC43" HREF="directions_toc.html#SEC43">Z-Script and Mail Management</A></H2>
<P>
<A NAME="IDX127"></A>
<A NAME="IDX128"></A>

</P>

<UL>

<LI>

Apply an arbitrary external index to an arbitrary folder for purposes
of sorting, restoring state, etc.

<LI>

Allow some way from Z-Script to add/modify headers of existing messages,
without resorting to <CODE>edit</CODE> of the entire message.  This is not
<A NAME="IDX129"></A>
possible with message stores like IMAP and is arguably improper in any
circumstance, but has been suggested as something users want to do.

<LI>

Arbitrary annotations of messages stored in folders.  This is preferable
to altering the headers.

<LI>

Save "replied" information for each message (to track how often
and the details about each time a message was replied to).  It
would also be desirable to save this information about "forwarded,"
"printed," etc...

<LI>

Provide user-definable sort operations (to allow sort on message body
contents, arbitrary headers, etc.).

<LI>

Convert open folder from read-only to writable (without reparsing)

<LI>

Make <CODE>record_user</CODE> a multivalue or something so you can specify that it
forcibly create the files instead of requiring that they exist.

<LI>

Attach a time string to the <CODE>New mail in <EM>folder</EM></CODE> message.

<LI>

Make more commands know about the <CODE>#</CODE> abbreviation for
<STRONG>previous folder</STRONG>.

<LI>

There needs to be a better way than <CODE>$%?status?</CODE> to test the state of
a message for deleted-ness, etc.

<LI>

It would be extremely useful to have variables that are local to a given 
composition or read window.  This would be used, for example, to
implement menu toggles that are then read during a send.

<LI>

The presentation of folders is absolutely critical.  This is described
in several ways in the document, but I<A NAME="FOOT25" HREF="directions_foot.html#FOOT25">(25)</A> want
to highlight it again.  Many, many applications (including Mariner) are
using the hierarchical tree representation; this has rapidly becoming a
real requirement.  We get bashed daily on this one. Even a graphical
representation of the existing V7 mail folders would be a great improvement.

</UL>



<H2><A NAME="SEC44" HREF="directions_toc.html#SEC44">Z-Script Language Wish-List</A></H2>
<P>
<A NAME="IDX130"></A>
<A NAME="IDX131"></A>

</P>
<P>
These are all items that have been on our Z-Script wish-list for some time.

</P>

<UL>

<LI>

Truly support "sticky" or read-only Z-Script variables, functions,
buttons, etc. so that the sysadmin can create things or make settings
that the user cannot remove or change.

<LI>

Provide text piping and capture.

<LI>

Add text-manipulation capabilities (get a regex library somewhere, or
perhaps even link with <STRONG>Perl</STRONG> or the like).  This is partly present
with the new <CODE>match</CODE> command, but still incomplete for large
bodies of text and text in external files.

<LI>

Make folders, messages, etc. into real hierarchical objects.

<LI>

Permit the user to define his own objects.

<LI>

Provide more features of modern programming languages (better
looping constructs, local variables, etc.)

<LI>

Permit filtering operations that rearrange messages or folders, e.g.
<CODE>sort</CODE> and <CODE>update</CODE>.  Either restrict to happening after all
other filters have finished, or perhaps the new message group design
will handle.

<LI>

More commands need "query" modes, e.g. a way to test whether an alias
or an ignored header are already set.  (Those two particular examples
are now possible.)

<LI>

Add Z-Script commands <CODE>lock</CODE>/<CODE>unlock</CODE> to apply dot-lock (and/or
kernel locking?) to arbitrary files.

<LI>

New syntax for the <CODE>msg_list</CODE> command to step through a list
of messages (<CODE>msg_list -next</CODE> etc.)

<LI>

Have the <CODE>set</CODE> command show all `builtin' variables all the time, with
the value of those booleans that are not set shown as "false."  Make

<PRE>
set foo = false    set foo = off    set foo = no    unset foo
</PRE>

all be equivalent.  (This one may not be a good idea, but it was
suggested, so here it is.)

<LI>

Put back the <CODE>-execute</CODE> option to the <CODE>filter</CODE> command.

<LI>

Read ELM-style <STRONG>system aliases</STRONG> and allow users to view/select from them.

<LI>

The <CODE>sound</CODE> command has been compiled out, and it should be
fixed (for all platforms, or just all UNIX?) and restored.

<LI>

The <CODE>menu</CODE> command should report labels for system-defined menus.

<LI>

If a user tries to write modular functions (ie, their .zmailrc sources
other files), upon a save it all dumps into the single file.  This makes
maintenance tough.  This is especially true for system-defined functions,
like when startup_hook is used at a system level.  Perhaps if Z-Script
"knew" where a function was defined it could avoid saving it later.

</UL>



<H1><A NAME="SEC45" HREF="directions_toc.html#SEC45">Other Unresolved Issues</A></H1>

<P>
Everything here is related in some way to section <A HREF="directions.html#SEC30">Code Sharing</A>.

</P>



<H2><A NAME="SEC46" HREF="directions_toc.html#SEC46">Programming Languages</A></H2>

<P>
Much of the existing Z-Mail code base is written in <STRONG>C</STRONG>, and in
the older dialect typically known as <STRONG>K&#38;R</STRONG> to boot.  This has been
necessary for portability of the code to a wide range of platforms.
<A NAME="IDX132"></A>
An increasing amount, however, is written in <STRONG>C++</STRONG>, especially on
the Windows and Macintosh platforms where extensive C++ development
libraries are available.  Further, most of the potential development
discussed in this document is either new work or requires extensive
changes to existing code.  The opportunity to convert more of our
development to C++ thus presents itself.

</P>
<P>
Unfortunately, this picture is not as rosy as it may at first seem.
C++ is not supported on all the UNIX platforms to which we presently
port, so we might have to drop some (which is, admittedly, not
necessarily a bad thing).  Even on those platforms where it <EM>is</EM>
supported, the level of support for various C++ language features is
inconsistent at best; this is true even for Windows and Macintosh,
not just for various flavors of UNIX.

</P>


<H2><A NAME="SEC47" HREF="directions_toc.html#SEC47">Message Store Object Model</A></H2>
<P>
<A NAME="IDX133"></A>

</P>
<P>
The documents <CITE>Message Store API Requirements</CITE><A NAME="FOOT26" HREF="directions_foot.html#FOOT26">(26)</A>
<A NAME="IDX134"></A>
and <CITE>Message Store API</CITE><A NAME="FOOT27" HREF="directions_foot.html#FOOT27">(27)</A>
outline an access model for electronic mail databases.  There is some
<A NAME="IDX135"></A>
bias towards support of MIME structure in the API, but an effort was
made to make the model extensible to other formats and to avoid any
reliance on a any particular form of persistent storage or access to
that storage.

</P>
<P>
It was the intent of the message store design that any shared code that
needed structured access to the message store (mail database) could use
the API, thus acting independently of the ultimate representation of
the database and whatever direct access methods it provides.  However,
this means that (by definition) the message store model and API have many
parallels to other systems designed to provide similar functionality; in
particular, Extended MAPI overlaps extensively with our design.
<A NAME="IDX136"></A>

</P>
<P>
This raises the same issue already stated in more general terms in
section <A HREF="directions.html#SEC30">Code Sharing</A>.  To wit, do we use shared code and implement the
message store API in terms of MAPI or other similar interfaces; or
do we re-implement any module that needs access to the database for
each such interface?

</P>
<P>
It is important to note that choosing to re-implement any module for a
specific interface (such as MAPI) does not necessarily mean that we
re-implement it for every possible message store access method.  In
many cases it will be an obvious win to map low-level protocols onto
a higher-level message store API.  However, a further question has
been raised:  If we decide to re-implement it even once, such as for
MAPI, does that mean that we should choose not to use our own API at
all, but instead adopt the MAPI model and implement <EM>that</EM> on
those platforms that don't already have a suitable high-level API?

</P>
<P>
An important consideration in answering the latter question is that
our API is considerably less complex than full Extended MAPI, and is
better tailored to the Internet-standard messaging model that we have
chosen as our primary means of connectivity.  Investigation is needed
to determine if a subset of MAPI would provide the appropriate level
of detail and functionality.

</P>


<H1><A NAME="SEC48" HREF="directions_toc.html#SEC48">Additional Features</A></H1>

<P>
These are wish-list items and other ideas or requests that don't fit into
any specific categories.

</P>

<UL>

<LI>

Do some kind of recovery of orphaned temp files, and attempt to provide
a user interface for it.

<LI>

The name of the spool folder should be available from a variable, maybe
$mail (reflected from env. MAIL if that is set at startup).

<LI>

Randomize the time between newmail checks in an idle GUI-mode Z-Mail to
avoid problems wherein multiple users hit the mail spool area or the
license server at the same time.

<LI>

Point the current message at a prioritized message if there are no new
or unread ones on startup.

<LI>

Explain what version of the variables file was found when it doesn't match
the version you expected.

<LI>

Make the GUI in all version able to recognize stop-button presses on
the task meter or other dialog while the core is running waited-for
external commands, so the GUI can kill the external job and interrupt
the core.  E.g. a <SAMP>`Cancel'</SAMP> button on the directory-service lookup
dialog might do this.  See section <A HREF="directions.html#SEC27">Multithreading</A>.

<LI>

The text window sizes (32K) on Windows and Mac are a real problem.

<LI>

Printing capabilities on the Windows and Mac platforms are truly
abysmal when compared to word processors with sophisticated print
controls.  We need a built-in <CITE>mailp</CITE><A NAME="FOOT28" HREF="directions_foot.html#FOOT28">(28)</A> type of capability.

<LI>

Management issues like password changes, vacation scripts, host-side
alias or mail list management, and other support functions need to be
addressed for Z-Mail users, especially the Windows or Mac-based ones.
<A NAME="IDX137"></A>
IMSP supports remote password and address book management, and its
attribute-value pair remote options mechanism could be employed to
support other functions.  See section <A HREF="directions.html#SEC24">IMSP</A>.

<LI>

Application management will be a an issue over time.  How does one
upgrade the software automatically?  Could Z-Mail, for instance, copy
itself from a server and update the main program or files that are not
in <CODE>$ZMLIB</CODE>?

</UL>



<H1><A NAME="SEC49" HREF="directions_toc.html#SEC49">Remarks</A></H1>



<H1><A NAME="SEC50" HREF="directions_toc.html#SEC50">Index</A></H1>

<P>
<H2>a</H2>
<DIR>
<LI><A HREF="directions.html#IDX74">Address Books</A>
<LI><A HREF="directions.html#IDX72">Address Lookup</A>
<LI><A HREF="directions.html#IDX62">Apple Guide</A>
<LI><A HREF="directions.html#IDX118">Apple Object Model</A>
<LI><A HREF="directions.html#IDX51">AppleScript</A>
<LI><A HREF="directions.html#IDX9">Asynch Support</A>
</DIR>
<H2>b</H2>
<DIR>
<LI><A HREF="directions.html#IDX1">Baseline Assumptions</A>
<LI><A HREF="directions.html#IDX5">binhex</A>
</DIR>
<H2>c</H2>
<DIR>
<LI><A HREF="directions.html#IDX132">C++</A>
<LI><A HREF="directions.html#IDX66">CDE</A>
<LI><A HREF="directions.html#IDX7">Character Set Translation</A>
<LI><A HREF="directions.html#IDX102">Code Sharing</A>
<LI><A HREF="directions.html#IDX123">Command-Line Interface</A>
<LI><A HREF="directions.html#IDX65">Common Desktop Environment</A>
</DIR>
<H2>d</H2>
<DIR>
<LI><A HREF="directions.html#IDX83">Database Aspects</A>
<LI><A HREF="directions.html#IDX55">Desktop Integration</A>
<LI><A HREF="directions.html#IDX73">Directory Services</A>
<LI><A HREF="directions.html#IDX67">Drag and Drop</A>
<LI><A HREF="directions.html#IDX100">Dynamic Features</A>
<LI><A HREF="directions.html#IDX101">Dynamic Loading</A>
</DIR>
<H2>e</H2>
<DIR>
<LI><A HREF="directions.html#IDX43">E-Mail Technology</A>
<LI><A HREF="directions.html#IDX71">Embedded Images</A>
<LI><A HREF="directions.html#IDX96">Enabled Mail</A>
<LI><A HREF="directions.html#IDX136">Extended MAPI</A>
</DIR>
<H2>f</H2>
<DIR>
<LI><A HREF="directions.html#IDX29">FlexLM</A>
<LI><A HREF="directions.html#IDX92">Forms</A>
</DIR>
<H2>h</H2>
<DIR>
<LI><A HREF="directions.html#IDX94">HTML+</A>
<LI><A HREF="directions.html#IDX95">HTTP</A>
</DIR>
<H2>i</H2>
<DIR>
<LI><A HREF="directions.html#IDX129">IMAP</A>
<LI><A HREF="directions.html#IDX99">IMAP4</A>
<LI><A HREF="directions.html#IDX137">IMSP</A>
<LI><A HREF="directions.html#IDX42">Interoperability</A>
</DIR>
<H2>l</H2>
<DIR>
<LI><A HREF="directions.html#IDX28">License Server</A>
<LI><A HREF="directions.html#IDX120">Lite</A>
<LI><A HREF="directions.html#IDX22">Local Directory</A>
<LI><A HREF="directions.html#IDX6">Localization</A>
<LI><A HREF="directions.html#IDX41">Look and Feel</A>
</DIR>
<H2>m</H2>
<DIR>
<LI><A HREF="directions.html#IDX113">Macintosh</A>
<LI><A HREF="directions.html#IDX27">MacMIME</A>
<LI><A HREF="directions.html#IDX87">Mail Interactions</A>
<LI><A HREF="directions.html#IDX128">Mail Management</A>
<LI><A HREF="directions.html#IDX89">Mail Transport Agent</A>
<LI><A HREF="directions.html#IDX40">Marathon</A>
<LI><A HREF="directions.html#IDX112">Mariner</A>
<LI><A HREF="directions.html#IDX134">Message Store API</A>
<LI><A HREF="directions.html#IDX133">Message Store Object Model</A>
<LI><A HREF="directions.html#IDX104">MFC</A>
<LI><A HREF="directions.html#IDX85">MH</A>
<LI><A HREF="directions.html#IDX78">Microsoft Exchange</A>
<LI><A HREF="directions.html#IDX135">MIME</A>
<LI><A HREF="directions.html#IDX122">Motif</A>
<LI><A HREF="directions.html#IDX79">MSX</A>
<LI><A HREF="directions.html#IDX88">MTA description language</A>
<LI><A HREF="directions.html#IDX98">Multithreading</A>
</DIR>
<H2>n</H2>
<DIR>
<LI><A HREF="directions.html#IDX111">NCD Software</A>
</DIR>
<H2>o</H2>
<DIR>
<LI><A HREF="directions.html#IDX68">Object-Oriented User Interface</A>
<LI><A HREF="directions.html#IDX108">OLE2</A>
<LI><A HREF="directions.html#IDX110">OLE2 Component Architecture</A>
<LI><A HREF="directions.html#IDX109">OLE2 Integration</A>
<LI><A HREF="directions.html#IDX114">OpenDoc</A>
<LI><A HREF="directions.html#IDX81">OpenMail</A>
<LI><A HREF="directions.html#IDX117">OpenTransport</A>
<LI><A HREF="directions.html#IDX84">Oracle Mail</A>
</DIR>
<H2>p</H2>
<DIR>
<LI><A HREF="directions.html#IDX38">PCX</A>
<LI><A HREF="directions.html#IDX45">POP</A>
<LI><A HREF="directions.html#IDX34">POP3</A>
<LI><A HREF="directions.html#IDX80">Post</A>
</DIR>
<H2>r</H2>
<DIR>
<LI><A HREF="directions.html#IDX70">Rich Text</A>
<LI><A HREF="directions.html#IDX86">Rmail</A>
</DIR>
<H2>s</H2>
<DIR>
<LI><A HREF="directions.html#IDX97">Safe-TCL</A>
<LI><A HREF="directions.html#IDX47">Scripting</A>
<LI><A HREF="directions.html#IDX32">Security</A>
<LI><A HREF="directions.html#IDX8">Serial Dialup</A>
<LI><A HREF="directions.html#IDX44">SMTP</A>
<LI><A HREF="directions.html#IDX12">Spelling Checker</A>
</DIR>
<H2>t</H2>
<DIR>
<LI><A HREF="directions.html#IDX54">TCL</A>
</DIR>
<H2>u</H2>
<DIR>
<LI><A HREF="directions.html#IDX119">UNIX</A>
<LI><A HREF="directions.html#IDX126">User Interface</A>
<LI><A HREF="directions.html#IDX4">uuencode</A>
</DIR>
<H2>v</H2>
<DIR>
<LI><A HREF="directions.html#IDX50">Visual Basic</A>
</DIR>
<H2>w</H2>
<DIR>
<LI><A HREF="directions.html#IDX105">Windows</A>
<LI><A HREF="directions.html#IDX35">Windows95</A>
<LI><A HREF="directions.html#IDX131">Wish-List</A>
<LI><A HREF="directions.html#IDX93">Workflow Automation</A>
</DIR>
<H2>x</H2>
<DIR>
<LI><A HREF="directions.html#IDX14">X.400</A>
<LI><A HREF="directions.html#IDX77">X.500</A>
<LI><A HREF="directions.html#IDX115">X/Open</A>
<LI><A HREF="directions.html#IDX121">X11</A>
<LI><A HREF="directions.html#IDX116">XTI</A>
</DIR>
<H2>z</H2>
<DIR>
<LI><A HREF="directions.html#IDX24">Z-POP</A>
<LI><A HREF="directions.html#IDX130">Z-Script</A>
<LI><A HREF="directions.html#IDX23">Zync</A>
</DIR>

</P>

</BODY>
</HTML>
